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^^ST ORED VALUE ELECTRONIC CE RTLEICAIEJBRQCESSING 

RELATED APPLICATION 

This application claims domestic priority and Convention priority from prior 
United States provisional patent application Sen No. 60/121,956, filed February 25, 1999, 
entitled Stored Value Certificate System, by named inventors William L. Honnef and 
Donald L. Endres, the entire contents of which are hereby incorporated by reference as if 
folly set forth herein. 

FIELD OF THE INVENTION 

The present invention generally relates to data processing. The invention relates 
more specifically to methods, apparatus, systems and products that provide electronic 
stored value certificates. 

BACKGROUND OF THE INVENTION 

Electronic commerce systems, in which buyers can order and pay for products 
online, have gained wide use throughout the worid. Some electronic commerce systems 
may be used to process transactions with individual consumers, and others may be used to 
carry out transactions between business, known as business-to-business electronic 
commerce. 

The electronic commerce systems that interact with consumers generally collect 
online orders submitted by the individual consumer over a public data network. Normally, 
a consumer who wishes to order a product fills out and submits an online form, or 
answers a series of prompts from the electronic commerce system. The electronic 
commerce system sends the order information to a merchant that fulfills the order. Such 
electronic commerce systems are now widely used in connection with the global, packet- 
switched network of internetworks known as the Internet, and its system of browsers and 
servers known as the World Wide Web. 

In consumer-to-consumer commerce involving traditional, brick-and-mortar retail 
stores, gift certificates are widely used to transfer value, hi this approach, a first consumer 
(the gift certificate giver) contacts a retail store or catalog that is associated with a 
merchant. The first consumer requests a gift certificate of a particular amount, and 
transfers fonds to the merchant in an amount equal to the face value of the gift certificate. 
In some cases, the merchant requests and receives the name and identifying information 
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of a second consumer (the gift certificate receiver). The merchant delivers the gift 
certificate in paper form to the first consumer, who deUvers it to the second consumer. 
Alternatively, the merchant may deliver the certificate to the second consumer. At some 
point after delivery, the second consumer contacts the merchant, selects merchandise 
offered by the merchant, and tenders the gift certificate as payment for the merchandise. 
Sometimes the gift certificate receiver selects merchandise having a cost greater than the 
face value of the gift certificate, in which case the receiver also tenders additional fimds to 
cover the difference in value. 

Although this approach is familiar to consumers, it has significant disadvantages. 
Further, gift certificates are not readily available in electronic commerce for a variety of 
reasons. 

First, for an online merchant to implement an electronic gift certificate 
mechanism, generally the online merchant is required to construct supporting software 
and hardware infrastructure itself, or contract for its development. This requires 
significant resources and time to implement. Online merchants would greatly benefit from 
an ability to add electronic gift certificate capability to their online stores or sites without 
incurring development costs and delays. 

Second, gift givers purchase gift certificates in part to give the recipient more 
control over the selection of a gift. However, traditional gift certificates are merchant 
specific, that is, they can be redeemed only at the merchant who sold the certificate. 
Consumers prefer certificates that are redeemable at multiple merchants and at both 
online stores and physical stores. An example of a traditional, paper-based gift certificate 
that is redeemable at a plurality of merchants is tiie American Express Gift Cheque. There 
is a need for an electronic gift certificate mechanism that permits an online gift receiver to 
redeem an electronic gift certificate at any of a plurality of online merchants. 

A third drawback of known gift certificates is that they cannot be used as coupons 
or discount mechanisms. Presently, online merchants are investing significant resources to 
attract new customers to their online stores by offering promotions that include coupons 
and discounts. These two promotion mechanisms have limitations. For example, 
customers may receive many coupons and discount offers, and the use of coupons and 
discount offers tends to communicate the message that merchants' products are 
overpriced. Further, a consumer may use one promotional mechanism to visit an online 
merchant, but only a small percentage of such consumer visitors actually shop at the 
online merchant and purchase a product. A more compelling promotion tool is needed to 
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attract new customers who actually shop at a merchant site and complete the purchase 
process. 

Merchants are also interested in promotional mechanisms that have a fixed cost 
per new consumer. Some merchants also wish to run a promotion that allows a promotion 
certificate to be redeemed at a different merchant. For example, a publisher wanting to 
attract new consumers to their site may issue a certificate redeemable at multiple other 
merchant sites. As another example, a merchant may wish to issue a certificate that is 
redeemable at an affiliate merchant site. While various paper gift certificate approaches 
are available in traditional store and catalog promotions, there is a need for an online, 
electronic gift certificate approach that provides a certificate redeemable at single and 
multiple online merchant stores. 

Another disadvantage of existing approaches is that once a merchant has a new 
consumer, the merchant needs tools to keep the customer coming back the merchant 
online store. Some merchants have joined universal loyalty programs in which the 
customer earns points redeemable for airline miles or other products or services not 
supplied by the merchant. A more attractive merchant program would involve rewarding 
a fi-equent shopper with a merchant's own products to reduce costs and to keep a closer 
relationship with the customer. 

Currently there is no mechanism in which online merchants can deliver online, 
electronic loyalty certificates to frequent or valued customers. Further, there is a need for 
a loyalty certificate program that offers loyalty certificates redeemable for only a 
particular merchant's goods and services. 

Merchants also are continually looking for ways to motivate employees with 
incentive programs that are fied to attaining specific goals. Although some companies 
have used paper-based gift certificates as an employee incentive, no method is currently 
available to electronically issue and redeem incentive certificates over a network for the 
purpose of rewarding employees. There is a need for such reward programs for the 
purpose of benefiting both employers and employees. 

SUMMARY OF THE INVENTION 

The foregoing needs and objects, and other needs and objects that will become 
apparent from the following description, are achieved by the present invention, which 
comprises, in one aspect, a certificate processing system in which a certificate processor 
handles all details relating to issuing, notifying and redeeming electi-onic virtual 
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certificates. The certificate processor issues a graphical virtual certificate that looks and 
feels like it is actually the merchant's own certificate. At the merchant's option the 
processor also issues a paper representation of the virtual certificate. The certificate 
processor interacts logically and contractually exclusively with the merchant, and the 
merchant controls interaction with the consumer. The certificate processor tracks the 
outstanding value of the certificate. In one embodiment, the merchant holds the funds 
continuously fi-om the time of purchase through redemption. Alternatively, a certificate 
redeemable at a particular merchant may be issued fi-om a server or site not controlled or 
owned by that merchant; the party that owns or controls the server or site acts as issuer of 
the certificate, and holds funds in the form of stored value from the time of certificate 
purchase through redemption. A merchant administration application enables a merchant 
to manage certificate information. 

The system includes a Promotions Certificate mechanism that enables merchants 
to mass issue electronic Promotions Certificates to attract customers to their online store. 
Using a Promotions Certificate, merchants can electronically send a file of consumer 
email addresses and the amount or value of each certificate to the stored value certificate 
processor. The stored value certificate processor creates, loads, and issues the Promotions 
Certificates, and notifies the recipient using electronic mail (email). A consumer receiving 
the Promotions Certificate can use it at the designated merchant online store in exchange 
for selected goods and services. 

The system also includes a Loyalty Certificate that allows an online merchant to 
set up customer loyalty programs that result in awards of that merchant's goods or 
services. Each time a customer shops a particular online merchant site, the merchant 
credits a loyalty certificate based on a pre-determined fi-action of the purchase total. The 
consumer can check the balance of the loyalty certificate at any time, and redeem it for 
other goods or services of the merchant. 

hi another embodiment, an Incentive Certificate is issued and delivered through a 
network and provides employers with a new tool to positively influence employee 
behavior and performance. An employer provides an electronic list of each employee who 
is a part of the employer's incentive certificate plan. When a particular employee achieves 
a particular goal, the employer adds value to the incentive certificate associated with that 
employee. The employer may add such value by connecting to the system and posting the 
appropriate value amount, or by periodically sending an electi-onic file to the system that 
contains value or "load" amounts for each certificate. An employee can check the balance 
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of that employee's Incentive Certificate at any time and redeem it in exchange for goods 
and services selected at any participating merchant. 

The invention also encompasses an apparatus, system, and computer-readable 
medium that may be configured to carry out the foregoing steps. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The present invention is illustrated by way of example, and not by way of 
limitation, in the figures of the accompanying drawings and in which like reference 
numerals refer to similar elements and in which: 

FIG. 1 A is a block diagram of a stored value certificate processing system. 

FIG. IB is a block diagram of a second stored value certificate processing system. 

FIG. 2A is a block diagram of functional elements of a stored value certificate 
processing system that may interact with a stored value certificate processor and clients 
with which the processor may interact. 

FIG. 2B is a block diagram of ftmctions that may be carried out by a stored value 
certificate processor. 

FIG. 3A is a flow diagram of a Purchase Certificate ftinction. 

FIG. 3B is a flow diagram of Notification and Confirmation functions. 

FIG. 3C is a flow diagram of a Redeem Certificate (single tender) function. 

FIG. 3D is a diagram of an example of a certificate order form. 

FIG. 4A is a flow diagram of a Certificate Administration (Recipient- View 
Certificate) function. 

FIG. 4B is a flow diagram of a Certificate Administration (Purchaser—Notification 
Status) function. 

FIG. 4C is a flow diagram of a Merchant Administration (Recipient- View 
Certificate) ftinction. 

FIG. 5 A is a block diagram of a method of redeeming a stored value certificate 
that is redeemable only at one merchant or issuer. 

FIG. 5B is a block diagram of a method of redeeming a stored value certificate 
that is redeemable at a plurality of merchants or issuers. 

FIG. 6 is a block diagram of a computer system with which an embodiment may 
be implemented. 
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DETAILED DESCRIPTION 

A method and apparatus providing stored value electronic certificate processing is 
described. In the following description, for the purposes of explanation, numerous 
specific details are set forth in order to provide a thorough understanding of the present 
invention. It will be apparent, however, to one skilled in the art that the present invention 
may be practiced without these specific details. In other instances, well-known structures 
and devices are shown in block diagram form in order to avoid unnecessarily obscuring 
the present invention. 

OPERATIONAL CONTEXT 
- NETWORK STRUCTURE 

FIG. 1 A is a block diagram of a stored value electronic certificate processing 
system that represents a context in which an embodiment may be practiced. 

Client 102, which executes browser 104, is coupled logically to network 106. 
Client 1 02 is any network end station, such as a personal computer, workstation, or other 
device having a processor. Although one client 102 is shown in FIG. 1, in a practical 
system there may be any number of clients coupled to network 1 06. 

Browser 104 is one or more software or hardware elements that cooperate to read 
and display electronic documents that are formatted according to open protocols. An 
example of a commercial product that may be used to implement browser 104 is Netscape 
Navigator®. Network 106 is a collection of one or more devices and interconnecting 
elements that support data communications using open protocols. In one embodiment, 
network 106 is a public, packet switched data network such as the Internet. 

One or more merchant servers 108A, 108B, 108N, (do not see on diagram) etc., 
may execute a certificate issuance application 1 1 0 and also are logically coupled to 
network 106. Each merchant server 108 A, 108B, 108N is owned, operated, controlled by, 
or affiliated with one particular online merchant or certificate issuer. Merchant server 
108 A, 1 08B, 1 08N is one or more hardware or software elements that provides a point of 
contact between a user of client 102 and a merchant that is in the business of selling one 
or more products or services. Merchant server 108A, 108B, 108N may be located at the 
merchant '^s place of business, but this is not required. Normally merchant server 108 A, 
108B, 108N is a secure commerce server suitable for use with the World Wide Web, and 
also includes an HTTP (Web) server. Microsoft® Internet Information Server is an 
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example of a commercial product that is suitable for use as merchant server 108 A, 108B, 
iOSN. 

Issuance application 110 is one or more hardware or software elements that 
cooperate to carry out certificate issuance in cooperation with stored value certificate 
processor 1 12. Issuance application may include functions and routines that implement 
stored value certificate issuance, viewing, notification, redemption, and administration 
functions, as described fiirther herein. 

One or more separate merchant applications may be executed by merchant server 
108A, 108B, 108N and may comprise one or more hardware or software elements that 
cooperate to offer products or services to the consumer, display information about the 
products or services, and solicit orders for the products or services. Such merchant 
applications generally provide a main commercial interface of the merchant to the 
consumer or user. The merchant applications may retrieve and store data about products, 
services, consumers, and orders in a database 1 1 1 that is logically coupled to the merchant 
server 108 A, 108B, 108N and the Issuance application. 

A pa>TTient processor 1 13 may be coupled to merchant server 108 A, etc. for the 
purpose of submitting payment transactions to credit card clearance networks, the 
automated clearinghouse network, wire transfer networks, etc. For example, payment 
processor 1 1 3 can receive a credit card number and other credit card information ft-om 
merchant server 108A, etc., and can carry out a charge transaction through the credit card 
networks operated by Visa, Mastercard, American Express, and others. As a result, value 
is transferred fi-om an account of a purchaser to an account associated with the owner or 
operator of merchant server 108. 

Although the term "merchant" is used to identify merchant server 108, it maybe 
owned, operated or controlled by a non-merchant issuer, such as a third party issuer, 
credit card company, trade association, merchants association, bank, credit union, 
governmental organization, etc. 

Stored value certificate processor 1 12 is one or more hardware or software 
elements that service requests of merchants from clients to issue, notify, redeem, manage 
and report the status of one or more virtual electronic stored value certificates. It may be 
remote from merchant server 108 A, 108B, 108N or co-located with the merchant server. 
In the preferred embodiment, Stored value certificate processor 1 12 is remote fi-om 
merchant server 108 A, 108B, 108N and communicates with the merchant server through 
network 106 using an agreed-upon protocol. 
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Alternatively, stored value certificate processor 1 12 comprises two servers 
running in parallel at separate locations maintain certificate balances and manage 
transactions. Two servers connected to a public network through different access 
mechanisms, e.g., hitemet Service Providers, ensure connectivity in the case of a partial 
network failure. 

The stored value certificate processor 112 may store and retrieve information 
using a relational database 1 15, which serves as a core repository of certificate 
information. The database 115 includes stored programs and procedures that manage 
certificate purchaser, recipient, and merchant information, as well as balance, transaction, 
settlement, and customer service information. Database 115 also contains a record for 
each certificate that contains all information pertaining to a certificate. In one 
embodiment, database 1 15 is a relational database system having a Certificate table that 
contains one or more fields for certificate information. The specific nature of the fields 
and their use is described further below. 

FIG. IB is a block diagram of an alternative stored value electronic certificate 
processing system that represents a context in which an embodiment may be practiced. 

hi the embodiment of FIG. IB, merchant server 108 lacks an issuance apphcation 
and payment processor 1 13 is coupled to stored value certificate processor 1 12. In this 
arrangement, certificate processor 1 12 acts as a host for certificate issuance functions. 
Thus, certificate processor 1 12 issues certificates on behalf of the merchant that is 
associated with merchant server 108. In particular, certificate processor 1 12 may host one 
or more servers, electronic documents, or Web sites that appear to be associated only with 
one of a plurality of merchants, through branding, page content, etc. In this configuration, 
certificate processor 1 12 carries out all certificate processing tasks so that merchants need 
not implement such fianctionality at their servers or sites. Clients may connect to merchant 
server 108, select a certificate issuance hyperlink, and be redirected to certificate 
processor 1 12 without awareness on the part of the client that it has left the domain of the 
merchant server. The client may then carry out certificate processing functions in the 
same overall transaction used for the client to order products or services fi-om the 
merchant server 108. 

FIG. 2A is a block diagram of functional elements of a stored value certificate 
processing system that may interact with a stored value certificate processor. 

In one embodiment, stored value certificate processor 1 12 interacts with a 
plurality of servers or Web sites that are associated with different roles and fijnctions 
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involved in stored value certificate processing. In one preferred embodiment, stored value 
certificate processor 1 12 interacts with third party issuer 202, consumer 204, merchant 
206, promotions application 208, incentives application 212, and loyalty application 210. 
Each of the third party issuer 202, consumer 204, merchant 206, promotions application 
208, incentives application 212, and loyalty application 210 may be implemented in the 
form of a Web server, or as a Web site that is executed by a separate server or collectively 
executed by a single server. This architecture separates and organizes Web pages, scripts, 
and other software elements by fiinctional area and application type. Each of the third 
party issuer 202, consumer 204, merchant 206, promotions application 208, incentives 
application 212, and loyalty 2 1 0 links to the stored value certificate processor through one 
or more hyperlinks or script calls. 

Stored value certificate processor 1 12 uses network 106, which may be the public 
Internet, and secure communication protocols to communicate with merchant servers and 
client browsers. As its clients, stored value certificate processor 1 12 may interact with an 
individual computer lOA, a local area network 12 comprising multiple client computers, a 
workstation 1 4, etc. 

In one preferred embodiment, stored value certificate processor 1 12 comprises 
two parallel computer systems, each of which is logically connected to network 106 
through a separate network service provider. This tends to ensure uninterrupted operation. 
If the primary system goes offline, the secondary system takes over all processing. 

FIG. 2B is a block diagram of fiinctions that may be carried out by a stored value 
certificate processor and clients with which the processor may interact, hi one 
embodiment, stored value certificate processor can carry out a purchase certificate 
fiinction 222, notification and confirmation fijnctions 224, redeem certificate function 
226, certificate administration fiinctions 228, and merchant administration functions 230. 
Such fiinctions are described further below. 

- COMMUNICATION PROTOCOL 

In one embodiment, merchant server 108 A, 108B, 108N communicates with 
stored value certificate processor 1 12 using HTTP (Hypertext Transport Protocol) over a 
SSL (Secure Sockets Layer) connection. Messages are exchanged by performing one or 
more HTTP GET operations using name and value pairs as parameters. The name and 
value pairs are generated by client software residing on the merchant server 108. The 
merchant server returns a set of name and value pairs witii the resulting page, that are 
transparently received and translated back to the client. 



-9- 

SUBSTiTUTE SHEET (RULE 26) 



wo 00/51052 



PCT/USOO/05039 



The APPENDIX to this document sets forth field names, function calls that use 
the field values, the format of the fields, and the amount of database storage used for each 
field, of fields that may be used in database 1 15 and in messages that use the foregoing 
communication protocol. Such fields may be used in messages between merchant server 
1 08, or another server of a third party certificate issuer, to communicate with stored value 
certificate processor 112 and to carry out the fijnctions described herein. 

In an alternative embodiment, merchant server 108 A, 108B, 108N communicates 
with stored value certificate processor 1 12 using Simple Commerce Messaging Protocol 
(SCMP), which is defined in the document http://search.ietf.org/intemet-drafts/draft- 
amold-scmp-01.txt. SCMP is an open standard that provides secure, authenticated 
commerce messaging capabilities between a sending agent's application to a receiving 
agent's server. The response by the receiving agent's server to the sending agent is a reply 
for the transaction represented by the set of data in the message. SCMP enables merchant 
server 108A, 108B, 108N and stored value certificate processor 112 to perform on-line 
business transactions such that the merchant is fully authenticated, and the message 
cannot be repudiated. 

In the preferred embodiment, SCMP messages requesting the use of commerce 
application 112 are sent from the merchant server 108 A, I08B, 108N to stored value 
certificate processor 112. Each message contains fields that describe the application 
request and provide necessary information about the consumer or end user, the merchant, 
and the stored value certificate. Preferably, SCMP messages are digitally signed and 
converted to ASCII format for transmission over a Hyper Text Transfer Protocol (HTTP) 
connection, enabling the messages to pass through firewalls and proxy servers. 

Software elements that can send and receive SCMP messages are installed at or 
executed by merchant server 108 A, 108B, 108N and stored value certificate processor 
112. 

~ IMPLEMENTING STORED VALUE CERTIFICATE PROCESSING 
In one embodiment, stored value certificate processor 1 12 may be developed by 
creating one or more scripts that send SCMP messages requesting input fi-om merchant 
server 108 A, 108B, 108N. The scripts are written under Common Gateway hiterface 
(CGI), Active Server Protocol (ASP), Internet Server Application Programming hiterface 
(ISAPI), or Netscape Application Programming Interface (NSAPI) using pre-defined 
C/C++, Java, or Perl libraries. The libraries are commercially available firom CyberSource 
Corporation. 
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Alternatively, the interface may be developed using object software such as 
CyberSource's Digital Commerce Component (DCC) that automates SCMP scripting. The 
DCC supports SCMP messaging and provides an interface to reduce development effort. 
An application developer may add appropriate scripts to interpret the results of a request 
for a customer. 

- MESSAGE COMMUNICATIONS AND FORMATS 

In operation, client 102 connects through network 106 to merchant server 108 A, 
108B, 108N. A consumer who is operating cHent 102 and browser 104 uses the browser 
to display one or more electronic documents stored at merchant server 108 A, 108B, 108N 
including pages that display product and service information. One of the pages may relate 
to issuing or redeeming a virtual electronic stored value certificate. When a stored value 
certificate processing request is entered, merchant server 108 A, 108B, 108N exchanges 
one or more messages with stored value certificate processor 1 12 over network 106 to 
carry out order processing fianctions. 

Each message provides stored value certificate processor 1 12 with information 
about the stored value certificate processing fiinction that is being requested. The 
information may include: verification of the merchant as a legitimate merchant; 
identification of a ftinction, such as purchasing a certificate, confirming delivery, 
redeeming a certificate, or administrative functions; or end user information required by 
the requested stored value certificate ftinction. 

In one embodiment, the messages use the SCMP protocol, and the messages are 
created using scripts in C/C++ or Peri that call library fiinctions to send the messages. In 
another embodiment, an interface to a commerce-ready third-party server ("commerce 
ready platform") is used, and the interface composes and sends the messages. Examples 
of commercially available commerce-ready third-party servers are Microsoft® Site Server 
3.0, Commerce Edition; Microsoft® Active Server Pages; and BroadVision. One or more 
scripts are used to call the desired stored value certificate functions and interpret the 
results. 

Witiiin an SCMP message, separate fields specify information about (a) the 
particular stored value certificate ftinction that the issuance application 1 10 is requesting 
fi-om stored value certificate processor 112; (b) the value of the associated stored value 
certificate, if needed; and (c) the consumer who is placing the order. The stored value 
certificate processor 1 12 processes this information and retums other information as fields 
in a reply SCMP message. 
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A field in an SCMP message consists of the name of the field and a value. Thus, 
SCMP messages consist of a series of fields in name-value pairs, separated by newline 
characters. Two types of fields are recognized: order-level fields and offer-level fields. 

When the issuance application 110 is working with function libraries of stored 
value certificate processor 1 12, then order level fields may be used within C/C++, Perl, or 
Java scripts. The issuance application 1 1 0 references the fields directly, specifying name- 
value pairs as described in later sections in this chapter. When the issuance application 
1 10 is working with commerce-ready platforms, the merchant application uses an 
interface to specify field values, or where to find field values within a database or Web 
form. 

CERTIFICATE PROCESSING METHODS 
Specific processing methods for online, electronic virtual certificates are now 
described. In this description, the term "certificate" refers broadly to a stored value 
certificate, gift certificate, promotions certificate, incentive certificate, reward or loyalty 
certificate, or award certificate. Further, the term "issuer" is used broadly to refer to the 
party that issues a certificate and receives and holds purchase funds or value for the 
certificate. An issuer may be a merchant, or an issuer may be a third party that hosts a site 
from which a purchaser may obtain certificates recognized by a plurality of merchants. In 
still another altemarive, an issuer may be a third party that hosts a site or server that is 
private branded for a particular merchant, so that the site or server appears to be owned or 
operated by one particular merchant. 

~ PURCHASE CERTIFICATE FUNCTION 

Generally, in purchase certificate function 222, a purchaser or gift giver can 
purchase an electronic virtual stored value certificate, sometimes called Internet Gifl 
Certificates ("IGC") by communicating with merchant server 108 A, 108B, 108N or, in an 
alternate embodiment, by connecting to third party issuer site 202 of stored value 
certificate processor 1 12. The purchaser specifies the amount of the certificate, the 
recipient's name and email address, the purchaser's name, payment type, payment 
information, and email information, and a message from the purchaser to the recipient. 
Other information can be collected. Purchasers can also specify when they want the 
notification sent. The certificate is created, loaded, and notification is sent at the 
appropriate time. 
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Promotion Certificates, Loyalty Certificates, and Incentive Certificates typically 
are mass issued by stored value certificate processor 1 12 based on input in the form of an 
electronic file prepared by the sponsoring merchant or company. The electronic file is 
received by stored value certificate processor 1 12 and processed according to the 
sponsor's instructions. 

FIG. 3 A is a flow diagram of a Purchase Certificate fiinction. In block 301, a 
purchaser requests the purchase certificate function. In one embodiment, block 301 
involves a purchaser clicking on a certificate icon of a Web site of an online merchant. In 
response, the merchant requests a unique identifier for a new certificate, as shown by 
block 302. In one embodiment, a servlet software element executed by merchant server 
108 A, 108B, 108N calls purchase certificate function 222 of stored value certificate 
processor 1 1 2 using a network message that specifies a function in an application 
programming interface (API) of the stored value certificate processor. 

In response, stored value certificate processor 1 1 2 returns a unique identifier value 
to the merchant, as shown by block 303. In one embodiment, a stored procedure executed 
by database 1 1 5 of the stored value certificate processor generates a unique order number 
or Event Number. The Event Number is sequentially generated, to ensure that the 
transaction is not duplicated in the event that the purchaser presses the Purchase 
Certificate key more than once due to slow network conditions. 

At block 304, the merchant generates an image of a certificate and sends the 
image to a client, which displays it. FIG. 3D is a diagram of an example of a screen 
display that includes an image 300 of an electronic virtual stored value certificate as part 
of an order form. In a preferred embodiment, the image is configured with data entry 
fields that create the impression that the purchaser is filling out the certificate itself The 
fields may be embedded within the graphic image. Mandatory data entry fields may be 
highlighted in color or with a message. 

Examples of certificates include merchant or consumer gift certificates for an 
anniversary, holiday, birthday, or other gift occasion; loyalty program award certificates; 
employee reward certificates given for attaining specified goals; promotional certificates 
given by a merchant to recipients without purchase, for the purpose of inducing customer 
interest in the products or services of the merchant; etc. A merchant gift certificate is a 
certificate purchased at one merchant and redeemable only for goods or services of that 
merchant. A consumer gift certificate is a certificate purchased by a consumer from a 
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third party funds holder, and that is redeemable at any merchant who accepts such 
certificates. 

hi block 305, a purchaser associated with the chent system enters information 
about a certificate order. For example, a user of a client may enter data in fields of the 
order form shown in FIG. 3D. The information includes the name of the recipient, a 
network address of the recipient, such as an email address, and the initial face value of the 
certificate, i.e., the amount of the purchase by the purchaser. 

In one embodiment, an order form of the type shown in FIG. 3D includes a send 
date field 330, amount radio buttons 332, recipient name fields 334, 336, recipient 
location identifier 338, message field 340, purchaser name fields 342, purchaser address 
field 344. The client or user may enter a date on which to send the certificate to the 
recipient in the send date field 330. For example, the purchaser may wish to send the 
certificate on a holiday, birthday, anniversary date, etc. The purchaser selects one of the 
amount radio buttons 332 to indicate the initial face value of the certificate. 

Recipient name fields 334, 336 receive values identifying the name of the 
recipient of the certificate. Recipient location identifier 338 receives information that 
identifies where to send the certificate to the recipient. In the preferred embodiment, an 
email address of the recipient is provided. Message field 340 receives a greeting or other 
message from the purchaser to the receiver that will be delivered as part of the certificate. 
Purchaser name fields 342 identify the purchaser and are delivered as part of the 
certificate. Purchaser address field 344 identifies an address for use in sending 
confirmation and related information to the purchaser. Typically the purchaser address is 
an email address. 

After entering appropriate information in each of the fields, in block 305, the 
purchaser is given the opportunity to enter a password to protect the information that has 
been entered for the certificate. In one embodiment, a Retrieve button is displayed in the 
order entry form. If the purchaser selects the Retrieve button, then the merchant 
determines whether the purchaser has already entered a password in a prior transaction. 
To make such a determination, in block 307, the merchant requests customer payment 
information for the current purchaser fi-om the stored value certificate processor. In block 
307-1, the stored value certificate processor returns any customer payment information in 
its database for the current purchaser to the merchant. M block 307-2, the merchant 
determines whether the purchaser previously entered a password. If so, then the merchant 
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enters the password into a password field of the order form 300, as indicated by block 
307-3. 

If the purchaser has no information in the system, e.g., in database 1 15, then the 
purchaser is a new purchaser. Accordingly, the purchaser is prompted to enter identifying 
information such as an email address, password, purchaser's payment type and other 
payment information, name on the card, expiration date, purchaser's email information, 
purchaser and giver address, city, state, zip, and phone number. 

Thereafter, the certificate is re-displayed, filled in with the purchase information 
as well as a purchase summary, as indicated in block 309. The purchase summary may 
include the certificate cost, a service fee if applicable, and the total purchase amount that 
is charged to the purchaser's credit card or other purchase mechanism. The total purchase 
amount field is calculated automatically. A Purchase Certificate button may be displayed. 
Required fields are validated on the form, before they are sent to the stored value 
certificate processor, to ensure that they contain valid values. 

In block 309-1, the purchaser completes the purchase. In one embodiment, the 
purchaser enters purchase information using a client computer, and submits the purchase 
information and a purchase confirmation signal to the merchant. In response, in block 
310, the merchant requests the stored value certificate processor to carry out a certificate 
purchase fimction. In one embodiment, the merchant servlet calls a purchase certificate 
fimction of the stored value certificate processor. 

As indicated by block 313, the stored value certificate processor carries out the 
purchase fimction, and returns the order number associated with the certificate to the 
merchant. The purchase fianction may include validating the received data to ensure that 
all fields are filled out and contain appropriate data, hi one embodiment, the amount value 
is tested to ensure that it is within the merchant's minimum and maximum amounts. The 
email addresses each must have both an "@" symbol and "." symbol, in that order, 
separated by alphanumeric characters. The credit card number field must have only 15 or 
16 numbers between "0" and "9", a valid date value, and valid date to send value. The 
date to send value cannot specify a date in the past. 

Payment gateway routines are called to authorize the payment transaction. The 
payment gateway routines comprise one or more software elements that are executed by 
the stored value certificate processor, by the merchant server or by a separate commerce 
server. The call to the payment gateway routines is the same kind of function call that is 
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carried out by the merchant to authorize other product sales. For example, a credit card 
charge transaction is initiated. 

The order number that is returned to the merchant may include an authorization or 
denial code that indicates whether the payment transaction succeeded or failed. If the 
payment transaction failed, then the merchant communicates a denial message to the 
purchaser. 

If an authorization code is received, then a call is made from the merchant to the 
stored value certificate processor to create, load and activate the certificate. The call may 
include the certificate holder's name and email address, the purchaser's name, email 
address, activation date, short greeting message, merchant name, and merchant identifier 
as well as the redemption location code. The activation date is the then-current date, or 
the sending date of the notification, if different. 

The stored value certificate processor creates and activates a certificate record in 
the certificate database, based on the information received in the call. Customer Number 
and Card Number fields each are assigned a unique identifier value. In a preferred 
embodiment, each identifier value comprises a 15-digit randomly generated number, and 
a checksum digit. A cancellation date value is also created and stored. The cancellation 
date value is the sum of the current date value, plus a pre-determined certificate life value. 
The certificate life value is created and stored in a merchant administration record that is 
uniquely associated in the database with a particular merchant. A typical certificate life 
value is one (1) year. Further, a Notification Sent flag is set to "N" or "NO." The unique 
identifier value is also added to a notification utility data value for later use. 

The stored value certificate processor loads the activated certificate with the 
designated initial face value ("stored value") and generates a unique Order Number. The 
Order Number is the transaction number that is generated when the certificate is loaded. 
The stored value certificate processor then returns a Load transaction number to the 
merchant server. The Load transaction number can be used by the purchaser as a 
customer service reference number. 

In block 319, if the charge transaction succeeded, the merchant servlet displays a 
confirmation or "thank you" page by communicating appropriate information to the client 
of the purchaser. 

- NOTIFICATION AND CONFIRMATION FUNCTIONS 

FIG. 3B is a flow diagram of Notification and Confirmation fiinctions. Generally, 
Notification involves sending a message to the recipient on the appropriate date, 
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indicating that the recipient has been given a certificate. The recipient notification may 
include a message describing the certificate, the name of the purchaser or giver, and a 
hyperlink with an embedded certificate number to view the actual certificate. A 
confirmation message is sent approximately at the same time to the purchaser to inform 
the purchaser that the notification has been sent. The confirmation message also states 
that the purchaser will receive a Notification Failed message if the confirmation message 
is undeliverable. 

Referring now to FIG. 3B, in block 401, the stored value certificate processor 
sends a notification message to a recipient. In one embodiment, notifications are sent in a 
batch during a period of low network activity, e.g., at night. Notifications relating to 
certificates that have a send date of the current date may be sent immediately, as indicated 
by block 401-2. 

In block 402, the recipient receives the notification message, which includes a 
hyperlink containing the certificate number. The notification message also includes a 
notification reply address. In block 403, the sending date of the notification message is 
stored in the database, and the status of the message for the certificate is set to "pending 
sent" in the database. A Notification Status Date/Time value is also set in the database to 
the date and time at which the notification message was sent. 

In block 404, a Confirmation message is sent to the purchaser. 

Referring now to block 405-1, at some fiiture time, the stored value certificate 
processor determines whether the Notification message was returned as undeliverable. 
Block 405-1 may be carried out, for example, at a pre-determined time that is about one 
(1) to three (3) days later than the time than the Notification message is sent. If the 
Notification message was returned as undeliverable, then as shown in block 405-2, a 
Notification Failed message is sent to the purchaser. The Notification Failed message 
contains a hyperlink to a Notification Status page using the transaction number. 

If the Notification message has not been returned as undeliverable, then in block 
407, the Notification Statiis field of the database record for the certificate is updated to 
include the contents of the reply message, date and time. In block 408, the merchant 
provides the certificate processor with an address associated with a merchant customer 
service facility. For example, the merchant sends the certificate processor an email 
address of its merchant customer service mailbox. Subsequent messages are forwarded to 
that account. In block 409, after a specified number of days, the stored value certificate 
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processor will set the value of the Notification Status field from "pending sent" to "sent." 
This status change indicates a successful delivery. 
- REDEEM CERTIFICATE FUNCTION 

FIG. 3C is a flow diagram of a Redeem Certificate function that enables single 
tender and split tender certificate redemption. 

Generally, a certificate recipient is provided three (3) methods to redeem a 
certificate. First, the recipient may use its client and browser to connect directly to the 
stored value certificate processor and receive, in response, one or more electronic 
documents that include redemption links for various merchants. At that site, the recipient 
selects a link or logo of the merchant who issued the certificate. 

Second, in a private branded method of operation, the recipient may use a client 
and browser to connect to stored value certificate processor 1 12, which displays one or 
more electronic documents that are associated with a particular merchant. For example, 
stored value certificate processor i 12 supports a plurality of private-branded Web sites, 
each of which is associated with a different merchant. When the client connects to such a 
site, it appears to be the site of a merchant, even though it is hosted and operated by stored 
value certificate processor 1 12. 

Third, the recipient may use its client and browser to select a link or logo of the 
merchant who issued the certificate at the merchant server 108 or any other server or site. 

In one mode of operation, a certificate recipient ("customer") shops a merchant 
site and adds products or services to a virtual shopping cart, as in any other product 
purchase transaction involving the merchant. If appropriate, the customer selects a 
shipping method for the products. A virtual invoice is displayed with a form to indicate 
the payment method and shipping information. The payment area includes a field for the 
recipient to enter the certificate number. Optionally, the recipient's messaging address 
(e.g., email address) is provided for verification purposes. A drop-down list may be 
provided in the virtual invoice for selecting a type of certificate from among several types 
offered by the merchant. 

If the amount of the purchase is greater than the then-current stored value of the 
certificate, then the customer is prompted to enter a payment method and payment 
information, e.g., a credit card number. Following successful acceptance of the certificate 
as payment, the customer receives confirmation of the order and the remaining balance of 
the stored value of the certificate is displayed. 
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Referring now to FIG. 3C, in block 501-1, the recipient or customer shops a 
merchant site and selects a "checkout" option to request the merchant to compute an 
invoice for a purchase transaction. As a result, information identifying products or 
services selected by the customer is transferred to the merchant from the customer. In 
response, the merchant creates a virtual invoice of information for the transaction. In 
block 501-2, the merchant requests an event number from the stored value certificate 
processor. 

In block 501-3, the stored value certificate processor returns a unique event 
number that is associated with and may be used for tracking the transaction. Generating 
an event number may be carried out using a stored procedure of database 1 15. The event 
number may be sequentially generated to ensure that the transaction is not duplicated if 
the purchaser presses the Redeem Certificate button more than once due to slow network 
conditions. 

In block 501-4, the merchant displays the final invoice with pricing. The invoice 
may include data entry fields that receive further information from the customer, e.g., 
payment type, certificate number, and recipient address. Delivery information such as 
name, address and phone number may be received, based on the needs of the merchant. In 
block 503-1, the customer enters payment information. In block 503-2, the customer 
selects a Purchase button, or the equivalent, to confirm that the customer wishes to 
purchase the goods. In block 504, the merchant validates the order information, and calls 
a Redeem Certificate function of the stored value certificate processor. The function call 
includes the total balance of the order, hi block 506, the stored value certificate processor 
returns a result code and related information. 

Block 506 may involve the steps shown in connection with block 507 through 
block 510-4, inclusive. In one embodiment, as part of block 506, the stored value 
certificate processor responds by providing values for the amount of the purchase 
remaining after the stored value of the certificate is applied, the balance of stored value 
remaining on the certificate, a transaction number, and a resuh code. The result code may 
indicate an error, for example, if an invalid account number of recipient address is 
entered, if the certificate is inactive or expired. 

hi block 507, the stored value certificate processor determines whether, after 
applying the then-current stored value of the certificate, an amount due remains in the 
order. Block 507 also may involve evaluating the result code and taking appropriate 
action if an error has occurred. If there is a balance due, then in block 509, the balance 
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due is collected using the payment method previously specified by the consumer. For 
example, if the consumer provided a credit card number, a charge transaction for the 
balance due is initiated. In block 5 10-1, a determination is made whether the balance has 
been collected successfully. If so, then control passes to block 508, in which the merchant 
creates a purchase confirmation message and delivers it to the customer. Control is also 
passed to block 508 if the test of block 507 is negative, that is, when there is no balance 
due for the order. 

If the test of block 510-1 is negative, such that the balance cannot be collected 
using the payment method specified by the customer, then in block 510-2, the merchant 
sends a denial message to the customer. Further, in block 510-3, the merchant requests the 
stored value certificate processor to roll back the redemption transaction and restore the 
stored value of the certificate as it existed before the transaction started. In response, the 
stored value certificate processor carries out the rollback function, and returns the updated 
current stored value balance of the certificate to the merchant. 

Thus, a split tender function increases revenue by allowing the consumer to 
purchase more than the stored value certificate amount and split the total sale between 
their certificate and other payment methods. 

FIG. 5 A is a block diagram of a method of redeeming a stored value certificate 
that is redeemable only at one merchant or issuer. 

Certificate Issuer 902 ?? requests stored value certificate processor 1 12 to issue a 
certificate and passes certificate parameters to stored value certificate processor 1 12. The 
certificate parameters specifically identify the certificate. For example, certificate 
parameters include certificate value, recipient name and address, a message, etc. 

Certificate parameters also include a merchant identifier 905 that is uniquely 
associated with one of a plurality of merchants 910. Each merchant has a unique merchant 
identifier, and a merchant group identifier. Merchant group identifiers associate one or 
more merchants in groups, all of which accept a particular certificate as tender for goods 
or services. In FIG. 5 A, each of the merchants 910 is identified with a symbol such as 
"lA," "3 A," "9C", etc. In each symbol, the numeric digit represents the merchant 
identifier and the alphabetic character represents the merchant group identifier. 

In response to receiving the parameters, stored value certificate processor issues a 
certificate 906 and binds or associates the merchant identifier 905 to the certificate. For 
example, the merchant identifier is stored as a value in database 1 1 5. When recipient 908 
wishes to redeem the certificate, only merchant 3A will recognize or accept the certificate 
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906 because merchant identifier "3" is associated only with merchant 3 A. Further, stored 
value certificate processor 1 12 will successfiilly cany out redemption functions only for 
certificates having merchant identifiers that match the associated merchant. 

FIG. 5B is a block diagram of a method of redeeming a stored value certificate 
that is redeemable at a plurality of merchants or issuers. 

As in FIG. 5A, certificate Issuer 902 requests stored value certificate processor 
112 to issue a certificate and passes certificate parameters to stored value certificate 
processor 1 12. The certificate parameters specifically identify the certificate. For 
example, certificate parameters include certificate value, recipient name and address, a 
message, etc. 

Certificate parameters also include a merchant group identifier 909 that is 
uniquely associated with a group of one or more among the plurality of merchants 910. 
For example, merchants 910 include a first group 912 (group "A") that includes a plurality 
of merchants such as merchants 914, and other groups 916 that include other merchants. 

In response to receiving the parameters, stored value certificate processor issues a 
certificate 906 and binds or associates the merchant group identifier 909 to the certificate. 
For example, the merchant identifier is stored as a value in database 115. When recipient 
908 wishes to redeem the certificate, only merchants in the group associated with the 
merchant group identifier will recognize or accept the certificate 906. In the example of 
FIG. 5B, only merchants 914 will accept certificate 906 because merchant group identifier 
"A" is associated only with merchants 914. Further, stored value certificate processor 1 12 
will successfiilly carry out redemption functions only for certificates having merchant 
group identifiers that match the associated merchant group. 

In this way, the use of a certificate may be limited or expanded in a flexible 
manner. A certificate carries metadata that indicates where the certificate may be 
redeemed. Issuance of promotional certificates good at only one merchant, or non-specific 
certificates that are good at a variety of merchants, is facilitated. 

- CERTIFICATE ADMINISTRATION FUNCTIONS 

FIG. 4A is a flow diagram of a Certificate Administration (Recipient-- View 
Certificate) fimction. Generally, a recipient may link to and view a certificate through a 
hyperlink in the Notification message that includes the certificate number ("hot link"), 
through a link at a server or site of the merchant, or through a link at stored value 
certificate processor 1 12 or another site or server of the certificate processor. 
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Referring now to FIG. 4 A, in block 621, a recipient selects a View Certificate 
function. Block 621 may involve three methods. First, a recipient may select a hot link 
that includes a certificate number in a Notification message; second, the recipient may 
select a link at a merchant server or site; third, the recipient may select a link at a server or 
site associated with the stored value certificate processor. 

In block 622, a determination is made whether a certificate number is in not the 
link or was otherwise received from the recipient, or is incorrect. If any such condition 
exists, then in block 623, the merchant displays a data entry form or prompt that requests 
the recipient to enter a valid certificate number. Control passes to block 624, in which the 
recipient enters a certificate number, and thereafter, control passes to block 622 to re- 
check the certificate number. 

When a valid certificate number has been received, then in block 620, the 
merchant requests certificate information for the certificate associated with the certificate 
number from the stored value certificate processor. The request may comprise a Java 
ftmction call to the stored value certificate processor to retrieve a certificate record using 
the certificate number as the search key. The recipient email address also may be used as 
a secondary key to provide additional security. 

In response, the stored value certificate processor attempts to retrieve certificate 
information from the database based on the certificate number. If the certificate number is 
valid, then the stored value certificate processor returns the certificate information, as 
shown by block 630. The returned certificate information may comprise the recipient 
name, purchaser name, message or greeting, stored value balance, expiration date, and 
transaction history. 

In block 640, the merchant displays the certificate information. Block 640 may 
involve creating a formatted display that resembles a paper certificate and sending the 
display information to the client of the recipient. 

FIG. 4B is a flow diagram of a Certificate Administration (Purchaser-Notification 
Status) fimction. Generally, the Purchaser-Notification Status ftmction enables a 
certificate purchaser to check on the status of notification and delivery. It also allows 
changes to be made to the stored values for the recipient's email address, notification date, 
and message or greeting. 

In block 65 1, the purchaser of a certificate selects the Notification Status fiinction. 
Preferably, the Purchaser-Notification Status function may be accessed by linking from a 
Notification Failed message, which contains an embedded order number and purchaser 
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address, or by linking from a merchant site. In block 652, the merchant server determines 
whether the fiinction selection includes an order number. This may involve examining an 
HTTP request received from the client of the purchaser to determine whether an order 
number is included as a parameter. 

If no order number is provided, or if the order number has an invalid format, then 
in block 653, the merchant generates a prompt or order form to the purchaser's client that 
requests the purchaser to enter a valid order number. In block 654, the purchaser enters an 
order number, and control is passed to block 652 to re-check the order number. 

When a valid order number is received, in block 660, the merchant requests order 
information from the stored value certificate processor. Block 660 may involve making a 
function call to the stored value certificate processor using the order number as a primary 
key. The purchaser's email address also may be used as a secondary key as a further 
security measure. 

In response, in block 670, the stored value certificate processor returns order 
information from the database to the merchant. The order information may comprise the 
recipient's name and email address, the purchaser's name and email address, a message or 
greeting, a certificate amount, a notification date, notification status information, a 
customer service address, and customer service telephone number. In block 680, the 
merchant creates display information for the certificate information and sends the display 
information to the client, which displays it. Block 680 may involve formatting the 
received information in a form that resembles a paper certificate, and displaying it as part 
of a Notification Status page. 

In block 682, the purchaser enters updated recipient information using the client. 
However, if the value of the notification status information indicates that the certificate 
has been picked up or redeemed by the recipient, the recipient information cannot be 
updated. To update the information in the database, the purchaser selects a Submit button 
or the equivalent, as shown by block 69 1 . In response, the merchant calls an Update 
Recipient function of the stored value certificate processor. This may involve calling a 
fiinction of the stored value certificate processor that updates the recipient's address and 
the notification date value, if they have changed. The merchant also requests the stored 
value certificate processor to update the Notification Status field to "sent", to appended to 
the date and time that the purchaser accessed the Notification Status page, and to add 
information indicating any actions taken by the purchaser. 
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In block 610, the stored value certificate processor updates the recipient 
information, and sets a value of a Notification Sent field to "sent." A notification message 
is re-sent to the recipient, if necessary, e.g., when the purchaser changes the recipient's 
email address, if the sending date value for the certificate has been changed to the current 
date, then the stored value certificate processor queues the certificate for sending by 
storing the certificate number in a Notification Utility Data File. The stored value 
certificate processor also returns an acknowledgment message to the purchaser. 

In block 612, the merchant displays the updated information. Block 612 may also 
involve sending an acknowledgment message from the stored value certificate processor 
to the merchant confirming that the notification status information has been updated. 

- MERCHANT ADMINISTRATION FUNCTIONS 

FIG. 5 is a flow diagram of a Merchant Administration (Recipient- View 
Certificate) application that may be implemented in association with the stored value 
certificate processor. Generally, Merchant Administration is an application that can 
interact with a browser to store and retrieve merchant information. The Merchant 
Administration application is executed by a server that is logically separate from, but may 
be associated with, the stored value certificate processor. Alternatively, the Merchant 
Administration application may be co-located with or executed by the same server that 
acts as the stored value certificate processor. Merchant Administration allows merchants 
to view business parameter data as well as certificate sales and inventory reports. 
Preferably, the Merchant Administration application is available only to issuers and not to 
purchaser or recipients. 

In block 701, a merchant selects the Merchant Administration function. In 
response, the Merchant Administration application provides a data entry form that accepts 
a user name and password, as shown by block 712. The merchant enters a user name and 
password and submits the values to the Merchant Administration application, as indicated 
by block 713. The merchant requests merchant information fi-om the stored value 
certificate processor, as indicated by block 720. This may involve making a function call 
to the stored value certificate processor to authenticate or validate the user name and 
password. In block 730, the stored value certificate processor looks up a merchant record 
in the database, validates the password, and returns a merchant identifier. In one 
embodiment, the stored value certificate processor loads a merchant parameter record 
from a merchant table of the database, and validates the password. 
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In block 741, a determination is made whether the merchant entered a correct 
password. If not, in block 742, the Merchant Administration application returns an error 
message to the client of the merchant. If validation is successful, then in block 743 the 
Merchant Administration application returns an initial page ("Welcome page") that 
presents fiinctional options for Merchant Setup, Merchant Reports, Customer Service, 
Exit, etc. 

In block 751, a Merchant Setup function is selected. The Merchant Setup ftinction 
is used to enter or change basic business parameters relating to the merchant. In response, 
the stored value certificate processor retrieves the data based on the merchant number. It 
validates the password and responds with the data. For example, as shown in block 761, 
the Merchant Administration application uses a function call to the stored value certificate 
processor to retrieve a merchant parameter record from database 1 1 5 using the merchant 
identifier and password as keys. In block 762, the stored value certificate processor 
returns the data to the Merchant Administration application. 

In response, the merchant server displays the data according to the read and 
modify properties that are assigned to each field, as shown by block 771. The merchant 
identifier is private to the system and is not displayed. Fields available to the merchant to 
modify are displayed. The merchant views or makes changes to the information, as 
indicated in block 772, and presses a Submit button or OK button to transfer the changes 
to the Merchant Administration application. 

In block 780, the Merchant Administration application updates the merchant 
information. For example, if changes are made to any modifiable field, then a function 
call is made to the stored value certificate processor to update the business parameter 
record. Before making the call, fields are validated for appropriate data. In block 790, the 
stored value certificate processor further validates the information and stores the updated 
record in the merchant parameter file. It responds back to the merchant server when the 
update is complete, as shown by block 710. The merchant server may notify the client 
that the data has been successfully updated. 

In block 71 1-1, the merchant selects a report function. Block 711-1 may involve 
displaying a list of available reports at the merchant's client computer. The merchant 
selects a desired report fi-om the list. In response, the Merchant Administration application 
calls the stored value certificate processor and requests the desired report using a report 
code associated with the report, as indicated by block 711-4. The report code may be 
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generated from a third party report package that allows the stored value certificate 
processor to add and modify merchant reports. 

In block 7 II -2, the stored value certificate processor returns the report data to the 
Merchant Administration application. In block 71 1-3, the Merchant Administration 
application displays the formatted report. 

OVERVIEW OF HARDWARE USEFUL IN AN IMPLEMENTATION 

FIG. 6 is a block diagram that illustrates a computer system 800 upon which an 
embodiment of the invention may be implemented. 

Computer system 800 includes a bus 802 or other communication mechanism for 
communicating information, and a processor 804 coupled with bus 802 for processing 
information. Computer system 800 also includes a main memory 806, such as a random 
access memory (RAM) or other dynamic storage device, coupled to bus 802 for storing 
information and instructions to be executed by processor 804. Main memory 806 also 
may be used for storing temporary variables or other intermediate information during 
execution of instructions to be executed by processor 804. Computer system 800 further 
includes a read only memory (ROM) 808 or other static storage device coupled to bus 802 
for storing static information and instructions for processor 804. A storage device 810, 
such as a magnetic disk or optical disk, is provided and coupled to bus 802 for storing 
information and instructions. 

Computer system 800 may be coupled via bus 802 to a display 812, such as a 
cathode ray tube (CRT), for displaying information to a computer user. An input device 
8 1 4, including alphanumeric and other keys, is coupled to bus 802 for communicating 
information and command selections to processor 804. Another type of user input device 
is cursor control 816, such as a mouse, a trackball, or cursor direction keys for 
communicating direction information and command selections to processor 804 and for 
controlling cursor movement on display 8 1 2. This input device typically has two degrees 
of freedom in two axes, a first axis (e.g., x) and a second axis (e.g., y), that allows the 
device to specify positions in a plane. 

The invention is related to the use of computer system 800 for automatically 
verifying address information. According to one embodiment of the invention, 
automatically verifying address information is provided by computer system 800 in 
response to processor 804 executing one or more sequences of one or more instructions 
contained in main memory 806. Such instructions may be read into main memory 806 
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from another computer-readable medium, such as storage device 810. Execution of the 
sequences of instructions contained in main memory 806 causes processor 804 to perform 
the process steps described herein. In ahemative embodiments, hard-wired circuitry may 
be used in place of or in combination with software instructions to implement the 
invention. Thus, embodiments of the invention are not limited to any specific 
combination of hardware circuitry and software. 

The term "computer-readable medium" as used herein refers to any medium that 
participates in providing instructions to processor 804 for execution. Such a medium may 
take many forms, including but not limited to, non-volatile media, volatile media, and 
transmission media. Non-volatile media includes, for example, optical or magnetic disks, 
such as storage device 810. Volatile media includes dynamic memory, such as main 
memory 806. Transmission media includes coaxial cables, copper wire and fiber optics, 
including the wires that comprise bus 802. Transmission media can also take the form of 
acoustic or light waves, such as those generated during radio-wave and infra-red data 
communications. 

Common forms of computer-readable media include, for example, a floppy disk, a 
flexible disk, hard disk, magnetic tape, or any other magnetic medium, a CD-ROM, any 
other optical medium, punchcards, papertape, any other physical medium with patterns of 
holes, a RAM, a PROM, and EPROM, a FLASH-EPROM, any other memory chip or 
cartridge, a carrier wave as described hereinafter, or any other medium from which a 
computer can read. 

Various forms of computer readable media may be involved in carrying one or 
more sequences of one or more instructions to processor 804 for execution. For example, 
the instructions may initially be carried on a magnetic disk of a remote computer. The 
remote computer can load the instructions into its dynamic memory and send the 
instructions over a telephone line using a modem. A modem local to computer system 
800 can receive the data on the telephone line and use an infra-red transmitter to convert 
the data to an infra-red signal. An infra-red detector can receive the data carried in the 
infra-red signal and appropriate circuitry can place the data on bus 802. Bus 802 carries 
the data to main memory 806, from which processor 804 retrieves and executes the 
instructions. The instructions received by main memory 806 may optionally be stored on 
storage device 8 1 0 either before or after execution by processor 804. 

Computer system 800 also includes a communication interface 818 coupled to bus 
802. Communication interface 818 provides a two-way data communication coupling to 
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a network link 820 that is connected to a local network 822. For example, 
communication interface 818 may be an integrated services digital network (ISDN) card 
or a modem to provide a data communication connection to a corresponding type of 
telephone line. As another example, communication interface 818 may be a local area 
network (LAN) card to provide a data communication connection to a compatible LAN. 
Wireless links may also be implemented. In any such implementation, communication 
interface 818 sends and receives electrical, electromagnetic or optical signals that carry 
digital data streams representing various types of information. 

Network link 820 typically provides data communication through one or more 
networks to other data devices. For example, network link 820 may provide a connection 
through local network 822 to a host computer 824 or to data equipment operated by an 
Internet Service Provider (ISP) 826. ISP 826 in turn provides data communication 
services through the world wide packet data communication network now commonly 
referred to as the "Internet" 828. Local network 822 and Internet 828 both use electrical, 
electromagnetic or optical signals that carry digital data streams. The signals through the 
various networks and the signals on network link 820 and through communication 
interface 818, which carry the digital data to and from computer system 800, are 
exemplary forms of carrier waves transporting the information. 

Computer system 800 can send messages and receive data, including program 
code, through the network(s), network link 820 and communication interface 818. In the 
Internet example, a server 830 might transmit a requested code for an application program 
through Internet 828, ISP 826, local network 822 and communication interface 8 1 8. In 
accordance with the invention, one such downloaded application provides for 
automatically verifying address information as described herein. 

The received code maybe executed by processor 804 as it is received, and/or 
stored in storage device 810, or other non- volatile storage for later execution. In this 
manner, computer system 800 may obtain application code in the form of a carrier wave. 

SCOPE OF DISCLOSURE 
In the foregoing specification, the invention has been described with reference to 
specific embodiments thereof. It will, however, be evident that various modifications and 
changes may be made thereto without departing from the broader spirit and scope of the 
invention. The specification and drawings are, accordingly, to be regarded in an 
illustrative rather than a restrictive sense. 
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A system or process configured in the foregoing manner offers numerous 
advantages over the prior art. For example, such a system or process may result in 
increasing first-time buyers at a particular online merchant site, converting shoppers to 
buyers, and increasing sales. The certificate processor is invisible to the consumer, stored 
value certificate purchaser and recipient, and handles all details of certificate issuance, 
redemption, statements, and transaction processing. A split tender function increases 
revenue of a merchant by allowing the consumer to purchase more than the stored value 
certificate amount and split the total sale between their certificate and other payment 
methods. 

Although such advantages are important, a system or process that falls within the 
scope of the appended claims is within the scope of the contemplated invention, 
regardless of whether such system or process actually achieves the advantages stated 
herein. Thus, the advantages should be considered as exemplary of one embodiment and 
not a requirement of conformance to the claims. 
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CLAIMS 

What is claimed is: 



11. A method of processing an electronic stored value certificate, comprising the 

2 computer-implemented steps of: 

3 receiving and storing certificate information that identifies a recipient of the 

4 certificate, a recipient address, and an amount of the electronic stored value 

5 certificate; 

6 issuing the electronic stored value certificate fi-om a certificate issuer in response 

7 to successfully carrying out a purchase transaction that transfers value fi-om 

8 a first account associated with a purchaser of the electronic stored value 

9 certificate to a second account associated with a merchant; and 

1 0 creating and storing a unique identification value for the electronic stored value 

1 ^ certificate in association with the certificate information as part of issuing 

12 the electronic stored value certificate; 

1 3 wherein the unique identification value is a random value that is non-negotiable in 

1 4 a commercial credit card network; 

1 5 wherein the unique identification value is operable for redemption of the electronic 
^ ^ stored value certificate at the merchant by communication of the merchant 

^ with the certificate issuer in a redemption transaction that does not traverse 

1 S the commercial credit card network. 



1 2. 
2 



A method as recited in Claim 1, fiirther comprising the steps of generating 
information defining a graphic image, in the form of a gift certificate, promotion 
3 certificate, incentive certificate, or award certificate, and that contains the 

certificate information, for display by a client computer associated with the 



5 recipient. 



13. A method as recited in Claim 1 , further comprising the steps of retrieving 

2 purchaser identifying information and purchaser payment information fi-om a 

3 database associated with the certificate issuer that is created as part of a prior sales 

4 transaction between the purchaser and the certificate issuer. 
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A method as recited in Claim 1, further comprising the steps of generating and 
dispatching a electronic mail notification message to the recipient of the electronic 
stored value certificate that includes a hyperlink that contains the unique 
identification value and links to a view certificate and statement function with 
which the recipient may view the certificate and statement within a browser. 

A method as recited in Claim 1, further comprising the steps of: 

receiving a request to redeem the electronic stored value certificate, wherein the 

request includes the unique identification value and an amount of an order 

placed by the recipient of the electronic stored value certificate; 
determining a current value of the electronic stored value certificate associated 

with the unique identification value; 
reducing the current value of the electronic stored value certificate by the amount 

of the order; 

generating and returning an amount redeemed to a merchant with which the 
electronic stored value certificate may be redeemed. 

A method as recited in Claim 1 , further comprising the steps of: 

receiving a request to redeem the electronic stored value certificate, wherein the 
request includes the unique identification value and an amount of an order 
placed by the recipient of the electronic stored value certificate; 

determining a current value of the electronic stored value certificate associated 
with the unique identification value; 

determining whether applying the current value of the electronic stored value 

certificate to the amount of the order results in a balance due for the order; 

applying the electronic stored value certificate to the order by reducing the current 
value of the electronic stored value certificate to zero and attempting to 
receive the balance due for the order by carrying out a charge transaction 
that transfers value from an account associated with the recipient of the 
electronic stored value certificate to a certificate issuer with which the 
electronic stored value certificate may be redeemed; 
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restoring the electronic stored value certificate to its previously determined current 
value in response to failure of the charge transaction. 

A method as recited in Claim 1, further comprising the steps of: 
receiving the unique identifier of an electronic stored value certificate from a 
certificate issuer; 

retrieving the certificate information that is associated with an electronic stored 

value certificate having the unique identifier; 
returning the certificate information to the certificate issuer in a pre-determined 

form; 

receiving updated recipient identifying information from the certificate issuer and 
updating the certificate information with the updated recipient information. 

A method as recited in Claim 1 , wherein creating and storing a unique 
identification value comprises the steps of: 
generating a random numeric value; 

combining the random numeric value with one or more constant numeric values to 
result in creating and storing a resulting numeric value; 

determining whether the resulting numeric value is currently associated with 
another existing certificate; 

storing the unique identification value when the resulting numeric value is not 
currently associated with another existing certificate. 

A method as recited in Claim 1, wherein the certificate is redeemable for goods or 
services of a party other than the certificate issuer. 
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A method as recited in Claim 1, further comprising the steps of: 

receiving a request to redeem the electronic stored value certificate at a party other 

than the certificate issuer, wherein the request includes the unique 

identification value and an amount of an order placed by the recipient of 

the electronic stored value certificate; 
determining a current value of the electronic stored value certificate associated 

with the unique identification value; 
reducing the current value of the electronic stored value certificate by the amount 

of the order; 

generating and returning an amount redeemed to the party other than the certificate 
issuer. 

A method as recited in Claim 1, fiirther comprising the steps of: 

receiving a request to tender the electronic stored value certificate as payment for 

an order, wherein the request includes the unique identification value and 

an amount of the order that is placed by the recipient of the electronic 

stored value certificate; 
determining a current value of the electronic stored value certificate associated 

with the unique identification value; 
determining whether applying the current value of the electronic stored value 

certificate to the amount of the order results in a balance due for the order, 

and if so, depleting the certificate value to zero and returning the total 

amount redeemed from the certificate to the merchant. 

A method as recited in Claim 1, wherein the certificate issuer is a third party 
reseller that issues a merchant branded certificate in exchange for receiving value 
paid by a purchaser of the certificate and wherein each certificate may be 
redeemed at a merchant for goods or services thereof 

A method as recited in Claim 1, further comprising the step of receiving, at a 
telephone call center, information requesting redemption of the electronic stored 
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3 value certificate as tender of all or a portion of payment for one or more goods or 

4 services. 



A method as recited in Claim 1, further comprising the step of receiving, at a 
physical store, information requesting redemption of the electronic stored value 
certificate as tender of all or a portion of payment for one or more goods or 



1 15. A method as recited in Claim 1, further comprising the steps of redeeming the 

2 electronic stored value certificate as tender of all or a portion of payment for goods 

3 or services only when the recipient selects such goods or services of a specified 

4 minimum purchase amount. 



A method as recited in Claim 1, further comprising the steps of redeeming the 
electronic stored value certificate as tender of all or a portion of payment for goods 
or services only when the recipient is making the recipient's first purchase of 
goods or services from a merchant who redeems the certificate. 



1 17. A method as recited in Claim 1 , further comprising the steps of redeeming the 

2 electronic stored value certificate as tender of all or a portion of payment for goods 

3 or services only for specified selected goods or services, wherein such specified 

4 selected goods or services are determined by a merchant who redeems the 

5 certificate. 



A method as recited in Claim 1, further comprising the steps of 
receiving from a merchant a request to process tender of payment for goods and 
services, wherein the request comprises, wherein the request includes (a) 
the unique identification value of the electronic stored value certificate, an 
amount of an order, and any applicable taxes, shipping or handling charges 
for an order that is placed by the recipient of the electronic stored value 
certificate and (b) an account number associated with a charge account or 
debit account of the recipient; 
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determining a current value of the electronic stored value certificate associated 

with the unique identification value; 
determining whether applying the current value of the electronic stored value 

certificate to the amount of the order results in a balance due for the order, 

and if so, depleting the certificate value to zero and charging the charge 

account or debit account for the balance due; 
generating a response to the merchant that comprises the total amoimt redeemed 

from the certificate to the merchant and the balance due that has been 

charged to the charge account or debit account. 

A method as recited in Claim 1, further comprising the steps of: 

receiving a request to redeem the electronic stored value certificate, wherein the 

request includes the unique identification value, an amount of an order, and 

any applicable taxes, shipping or handling charges, that is placed by the 

recipient of the electronic stored value certificate; 
determining a current value of the electronic stored value certificate associated 

with the unique identification value; 
determining whether applying the current value of the electronic stored value 

certificate to the amount of the order results in a balance due for the order, 

and if so, generating information that prompts the recipient to add value to 

the certificate. 

A method of redeeming an electronic stored value certificate, wherein the 
electronic stored value certificate has a pre-determined current face value that is 
stored in a database, has a unique identification value, and is associated with a 
purchaser and a recipient, the method comprising the steps of 
receiving a request to redeem the electronic stored value certificate, wherein the 

request includes the unique identification value and an amount of an order 

placed by the recipient; 
wherein the unique identification value is a random value that is non-negotiable in 

a commercial credit card network; 
wherein the unique identification value is operable for redemption of the electronic 

stored value certificate at the merchant by communication of the merchant 
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1 2 with the certificate issuer in a redemption transaction that does not traverse 

13 the commercial credit card network; 

14 determining, from the database, a current value of the electronic stored value 

15 certificate associated with the unique identification value; 

16 reducing the current value of the electronic stored value certificate by the amount 

17 of the order; 

1 8 generating and returning an amount redeemed to a merchant with which the 

1 9 electronic stored value certificate may be redeemed. 

1 21. A method of redeeming an electronic stored value certificate, wherein the 

2 electronic stored value certificate has a pre-determined current face value that is 

3 stored in a database, has a unique identification value, and is associated with a 

4 purchaser and a recipient, the method comprising the steps of 

5 receiving a request to redeem the electronic stored value certificate, wherein the 

6 request includes the unique identification value and an amount of an order 

7 placed by the recipient; 

8 wherein the unique identification value is a random value that is non-negotiable in 

9 a commercial credit card network; 

1 0 wherein the unique identification value is operable for redemption of the electronic 

^ ^ stored value certificate at the merchant by communication of the merchant 

^ ^ ^^^^ the certificate issuer in a redemption transaction that does not traverse 

1 3 the commercial credit card network; 

1 4 determining a current value of the electronic stored value certificate associated 
^ 5 with the unique identification value; 

1 6 determining whether applying the current value of the electronic stored value 

^ ^ certificate to the amount of the order results in a balance due for the order, 

^ ^ and if so, applying the current value of the electronic stored value 

^ ^ '^^rti ficate to the amount of the order and receiving the balance due for the 
order by carrying out a charge transaction that transfers value from an 

2 1 account associated with the recipient of the electronic stored value 

22 certificate to a merchant with which the electronic stored value certificate 

23 may be redeemed. 
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A method of redeeming an electronic stored value certificate, wherein the 
electronic stored value certificate has a pre-determined current face value that is 
stored in a database, has a unique identification value, and is associated with a 
purchaser and a recipient, the method comprising the steps of: 
receiving a request to redeem the electronic stored value certificate, wherein the 

request includes the unique identification value and an amount of an order 

placed by the recipient; 
wherein the unique identification value is a random value that is non-negotiable in 

a commercial credit card network; 
wherein the unique identification value is operable for redemption of the electronic 

stored value certificate at the merchant by communication of the merchant 

with the certificate issuer in a redemption transaction that does not traverse 

the commercial credit card network; 
determining a current value of the electronic stored value certificate associated 

with the unique identification value; 
determining whether applying the current value of the electronic stored value 

certificate to the amount of the order results in a balance due for the order; 
applying the electronic stored value certificate to the order by reducing the current 

value of the electronic stored value certificate to zero and attempting to 

receive the balance due for the order by carrying out a charge transaction 

that transfers value fi-om an account associated with the recipient of the 

electronic stored value certificate to a merchant with which the electronic 

stored value certificate may be redeemed; 
restoring the electronic stored value certificate to its previously determined current 

value in response to failure of the charge transaction. 

A computer system configured to process an electronic stored value certificate, 
comprising: 

a database that stores certificate information defining the electronic stored value 
certificate, including information idenfifying a recipient, recipient address, 
and amount of the electronic stored value certificate; 

one or more processors coupled to the database; 
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instructions coupled to the database and the processors which, when executed by 
the one or more processors, cause the one or more processors to carry out 
the steps of: 

receiving and storing certificate information that identifies a recipient of the 

certificate, a recipient address, and an amount of the electronic stored value 
certificate; 

issuing the electronic stored value certificate fi-om a certificate issuer in response 
to successfiilly carrying out a purchase transaction that transfers value from 
a first account associated with a purchaser of the electronic stored value 
certificate to a second account associated with a merchant; and 

creating and storing a unique identification value for the electronic stored value 
certificate in association with the certificate information as part of issuing 
the electronic stored value certificate; 

wherein the unique identification value is a random value that is non-negotiable in 
a commercial credit card network; 

wherein the unique identification value is operable for redemption of the electronic 
stored value certificate at the merchant by communication of the merchant 
with the certificate issuer in a redemption transaction that does not traverse 
the commercial credit card network. 



A computer-readable medium carrying one or more sequences of instructions for 
processing an electronic stored value certificate, wherein execution of the one or 
more sequences of instructions by one or more processors causes the one or more 
processors to perform the steps of: 

generating information defining display parameters of the electronic stored value 
certificate; 

receiving and storing stored value certificate information identifying a recipient, 
recipient address, and amount of the electronic stored value certificate; 

issuing and activating the electronic stored value certificate in response to 

successfully canying out a purchase transaction that transfers value from 
an account associated with a purchaser of the electronic stored value 
certificate to a certificate issuer, wherein the stored value certificate may 
be redeemed for goods and services at one or more merchants; 
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creating and storing a unique identification value in association with the stored 
value certificate information as part of activating the electronic stored 
value certificate; 

wherein the unique identification value is a random value that is non-negotiable in 

a commercial credit card network; 
wherein the unique identification value is operable for redemption of the electronic 

stored value certificate at the merchant by communication of the merchant 

with the certificate issuer in a redemption transaction that does not traverse 

the commercial credit card network. 

A method of processing an electronic promotional certificate that is redeemable at 
a merchant for goods or services, comprising the steps of: 
generating information defining display parameters of the certificate; 
storing certificate information identifying a recipient, recipient address, and 

amount of the certificate; 
issuing the certificate to a recipient without consideration; 

storing value in association with the certificate, wherein the value of the certificate 
may be redeemed at the certificate issuer store and may be redeemed at a 
one or more merchants from among a limited number of merchants 
specifically established by the certificate issuer, in exchange for goods or 
services; 

creating and storing a unique identification value in association with the certificate 
information as part of activating the electronic stored value certificate; 

wherein the unique identification value is a random value that is non-negotiable in 
a commercial credit card network; 

wherein the unique identification value is operable for redemption of the electronic 
stored^ value certificate at the merchant by communication of the merchant 
with the certificate issuer in a redemption transaction that does not traverse 
the commercial credit card network. 

A method of processing an electronic stored value certificate, comprising the steps 
of; 
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3 receiving a request to create the electronic stored value certificate, the request 

4 comprising certificate information that identifies a recipient of the 

5 certificate, a recipient address, and an amount of the electronic stored value 

6 certificate; 

7 issuing and activating the electronic stored value certificate in response to the 

8 request; 

9 creating and storing a unique identification value for the electronic stored value 

certificate in association with the certificate information as part of 

^ ^ activating the electronic stored value certificate; 

1 2 wherein the unique identification value is a random value that is non-negotiable in 

1 3 a commercial credit card network; 

1 4 wherein the unique identification value is operable for redemption of the electronic 
1 ^ stored value certificate at the merchant by communication of the merchant 

^ ^ with the certificate issuer in a redemption transaction that does not traverse 

1 "7 the commercial credit card network. 

1 27. A method of processing an electronic stored value certificate, comprising the steps 

2 of: 

3 receiving and storing certificate information that identifies a recipient of the 

4 certificate, a recipient address, and an amount of the electronic stored value 

5 certificate; 

6 issuing and activating the electronic stored value certificate in response to 

7 successfiilly carrying out a purchase transaction that ti-ansfers value fi-om 

8 an account associated with a purchaser of the electronic stored value 

9 certificate to a certificate issuer, wherein the electronic stored value 
^ ^ certificate may be redeemed for goods and services at one or more 

1 1 merchants; 

1 2 creating and storing a unique identification value for the electronic stored value 
^ ^ certificate in association with the certificate information as part of 

^ ^ activating the electronic stored value certificate; 

1 5 wherein the unique identification value is a random value that is non-negotiable in 

^ ^ a commercial credit card network; 
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wherein the unique identification value is operable for redemption of the electronic 
stored value certificate at the merchant by communication of the merchant 
with the certificate issuer in a redemption transaction that does not traverse 
the commercial credit card network. 

A method of processing an electronic stored value certificate, comprising the steps 
of 

receiving and storing certificate information that identifies a recipient of the 

certificate, a recipient address, and an amount of the electronic stored value 
certificate; 

by the merchant, issuing and activating the electronic stored value certificate in 

response to successfully carrying out a purchase transaction that transfers 

value from an account of a purchaser of the electronic stored value 

certificate to an account of the merchant; 
creating and storing a unique identification value for the electronic stored value 

certificate in association with the certificate information as part of 

activating the electronic stored value certificate; 
wherein the unique identification value is a random value that is non-negotiable in 

a commercial credit card network; 
wherein the unique identification value is operable for redemption of the electronic 

stored value certificate at the merchant by communication of the merchant 

with the certificate issuer in a redemption transaction that does not ti-averse 

the commercial credit card network; 
redeeming the electronic stored value certificate at the merchant in exchange for 

goods or services of the merchant. 

A method of processing an electronic stored value certificate, comprising the steps 
of: 

receiving and storing certificate information that identifies a recipient of the 

certificate, a recipient address, and an amount of the electronic stored value 
certificate; 
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by a third party host, generating a visual display comprising a purchaser payment 
input form that can receive information associated with a purchase 
transaction; 

by the merchant, issuing and activating the electronic stored value certificate in 
response to successfully carrying out a purchase transaction that transfers 
value from an account associated with a purchaser of the electronic stored 
value certificate to the merchant; 

by the merchant, receiving the electronic stored value certificate as tender of 
payment for a portion or all of one or more goods or services of the 
merchant; 

creating and storing a unique identification value for the electronic stored value 
certificate in association with the certificate information as part of 
activating the electronic stored value certificate; 

wherein the unique identification value is a random value that is non-negotiable in 
a commercial credit card network; 

wherein the unique identification value is operable for redemption of the electronic 
stored value certificate at the merchant by communication of the merchant 
wjth the certificate issuer in a redemption transaction that does not traverse 
the commercial credit card network. 



A method of processing an electronic stored value certificate, comprising the steps 
of: 

receiving and storing certificate information that identifies a recipient of the 

certificate, a recipient address, and an amount of the electronic stored value 
certificate; 

by a third party certificate reseller, issuing and activating the electronic stored 
value certificate in response to successfully carrying out a purchase 
transaction that transfers value from an account associated with a purchaser 
of the electronic stored value certificate to the third party certificate 
reseller; 

by the merchant, receiving the electronic stored value certificate as tender of 
payment for a portion or all of one or more goods or services of the 
merchant; 
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creating and storing a unique identification value for the electronic stored value 

1 5 certificate in association with the certificate information as part of 

16 activating the electronic stored value certificate; 

1 7 wherein the unique identification value is a random value that is non-negotiable in 

1 8 a commercial credit card network; 

1 9 wherein the unique identification value is operable for redemption of the electronic 
2^ stored value certificate at the merchant by communication of the merchant 
2 ^ with the certificate issuer in a redemption transaction that does not traverse 
22 the commercial credit card network. 

1 31. A method of processing an electronic stored value certificate, comprising the steps 

2 of: 

3 receiving and storing certificate information that identifies a recipient of the 

4 certificate, a recipient address, and an amount of the electronic stored value 

5 certificate; 

6 at a third party certificate issuer, issuing and activating the electronic stored value 

7 certificate in response to successfiiUy carrying out a purchase transaction 

8 that transfers value from -an account associated with a purchaser of the 
^ electronic stored value certificate to the third party certificate issuer, 

^ ^ wherein the electronic stored value certificate is redeemable at any of a 

1 1 ' plurality of merchants; 

1 2 at the merchant, receiving the electronic stored value certificate as tender of 
^ ^ payment for a portion or all of one or more goods or services of the 

14 merchant; 

1 5 creating and storing a unique identification value for the electronic stored value 
^ ^ certificate in association with the certificate infomiation as part of 

^ ^ activating the electronic stored value certificate; 

1 8 wherein the unique identification value is a random value that is non-negotiable in 

1^ a commercial credit cafd'network; 

20 wherein the unique identification value is operable for redemption of the electronic 

^ ^ stored value certificate at the merchant by communication of the merchant 
^i^^ certificate issuer in a redemption transaction that does not traverse 

23 the commercial credit card network. 
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PURCHASER 



301 



3.1 PURCHASER 
CLICKS ON THE GIFT 
CERTIFICATE ICON 
TO GAIN ACCESS 
TO THE PURCHASE 
CERTIFICATE PAGE 



305 
_^ 



3.5 PURCHASER 
ENTERS INFORMATION 
ABOUT IGC. 



3.6 THE PURCHASER 
IS THEN GIVEN THE 
OPPORTUNITY TO 
ENTER A PASSWORD 
(IN ADDITION TO THE 
EMAIL ADDRESS) 



306 



TO STEP 
307-2 



ISSUER 



STORED VALUE 
PROCESSOR 



3.2 THE MERCHANT 

SERVLET CALLS 
GET EVENT NUMBER. 



302 



3.3 THE SVP 
RETURNS THE 
UNIQUE EVENT 

NUMBERS. 



304 
^ 



3.4 THE MERCHANT 
SERVLET DISPLAYS 
THE INTERNET GIFT 
CERTIFICATE (IGC). 



303 



307 



3.7 THE MERCHANT 
SERVLET CALLS 
GET CUSTOMER 
PAYMENT INFO. 



307-1 



3.7.1 THE SVP 
RETURNS THE 

CUSTOMER 
PAYMENT INFO 
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307-3 



3.7 THE MERCHANT 
SERVLET FILLS IN THE 
PREVIOUS PAYMENT 
INFORMATION. 



3.9 THE MERCHANT 
SERVLET DISPLAYS 
FORMS WITH ENTRIES 
FOR THE PURCHASE 
INFORMATION AS WELL 
AS PURCHASE 
SUMMARY AREA. 



309-1 

_z i 

3.9.1 THE 
PURCHASER 
ENTERS PURCHASE 

INFORMATION 
AND THEN PRESSES 
"PURCHASE 
CERTIFICATE" BUTTON. 



310 



3.10 THE MERCHANT 
SERVLET CALLS 
PURCHASE 
CERTIFICATE. ' 



313 



3.13 THE SVP 
RETURNS THE 
ORDER NUMBER. 



319 



3.19 THE MERCHANT 
SERVLET DISPLAYS 
THANK YOU PAGE. 
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401 



401-2 



403 



4.1.1 THE SVP 
SENDS NOTIFiCATION 
NIGHTLY TO 
RECIPIENTS. 



4.1.2 THE SVP 
SENDS NOTIFICATIONS 
IMMEDIATELY IF THE 
SEND DATE IS TODAY. 



4.3 THE SENDING DATE 
IS RECORDED AND THE 
MAIL STATUS IS SET TO 
"PENDING SET". 
THE NOTIFICATION 
STATUS DATE/TIME 
IS ALSO SET. 



7/17 

402 RECIPIENT 



PURCHASER 



4.2 RECIPIENT RECEIVES 
MESSAGE WHICH 

INCLUDES HOT-LINK WITH 
CERTIFICATE NUMBER, 

ALSO HAS NOTIFICATION 
REPLY ADDRESS. 



404 



4.4 THE 
CONFIRMATION 
MESSAGE IS 
SENT TO THE 
PURCHASER. 



405-1 



4,5.1 
WAS THE 
NOTIFICATION EMAIL 
IS RETURNED 



407 - 



408 - 



1 YES 


4.5.2 THE 
PURCHASER RECEIVES 
NOTIFICATION FAILED 

MESSAGE WHICH 
CONTAINS HOT-LINK TO 
NOTIFICATION 
STATUS PAGE USING 
THE TRANSACTION 
NUMBER. 


4.7 THE 
NOTIFICATION STATUS 

FIELD SHOULD BE 
UPDATED TO INCLUDE 
THE REPLY MESSAGE, 

DATE, AND TIME. 













MERCHANT PROVIDES 
A CUSTOMER SERVICE 
MAILBOX. MESSAGES 
ARE FORWARDED TO 
THIS ACCOUNT. 



4.9 AFTER A 
SPECIFIED NUMBER OF DAYS, 

THE SVP WILL SET THE 
"PENDING SENT" TO "SENT". 
THIS WILL INDICATE A 
SUCCESSFUL DELIVERY. 



405-2 
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PROCESSOR 



5.1.1 THE 
CUSTOMER SHOPS 
THE SiTE. PRESSES 
CHECKOUT. 



5.1.2 THE 
MERCHANT SERVLET 
CALLS GET EVENT 
NUMBER. 



501-2 



3.3 THE SVP 
RETURNS THE 
UNIQUE EVENT 

NUMBERS. 



503-1 



5.3.1 CUSTOMER 
ENTERS PAYMENT 
INFORMATION. 



501-4 



5.1.4 THE 
MERCHANT SERVLET 
DISPLAYS THE FINAL 

INVOICE. 



501-3 



5.3.2 CUSTOMER 
PRESSES PURCHASE 
KEY. 



503-2 



5.4 THE MERCHANT 
SERVLET VALIDATES THE 
INFORMATION AND CALLS 

REDEEM CERTIFICATE 
AND SENDS THE TOTAL 

BALANCE TO THE SVP. 
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506 



5.6 THE SVP 
RETURNS A RESULT 
CODE AND OTHER 
INFORMATION. 
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5.10.2 MERCHANT 
SERVER SENDS 

DENIED MESSAGE 
TO CUSTOMER. 



5.10.4 THE SVP 
RETURNS THE 
CURRENT BALANCE. 
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GIFT CERTIFICATE ORDER FORM 



$50.00 



(YOUR LOGO HERE) M 

I ■^''^^ Jllp^" ' " TO:" FRANK PATRICK ' :^^^"v$^' 

■ "^'^^^v ^^^'^^ "^^^^ SMITH ^'"'^r--i^'''^''"''''Certificate #: 




Your custom message goes here. 



|j 1234123412341234 

P Expiration: 

!l 02/22/2001 



332 



SENDQnT I Feb ~JT] I 23 | t | | 2000 | t | 

^ Specify gift certificate amount. You can choose from 10 to $500. 

o $10 
o $25 
o $50 

o $100 



© other 75 



J {whole dollars only) 



RECIPIENT INFORMATION 



V= Required Ent 



First Name V 



334 4 



Last Name V 



^336 



Email Address V 
338 



Add your own personalized greeting (max 255 characters) optional 



340 



PURCHASER INFORMATION 



First Name V 



Last Name V 



344 ^ 



Email Address V 



2] 



342 



Submit 
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PROCESSOR 



6.1.1 RECIPIENT 
CLICKS ON VIEW 
CERTIFICATE 



6.1.4 RECIPIENT 
ENTERS IGC 
NUMBER. 




6.2 THE MERCHANT 
SERVLET CALLS 
GET IGC. 



6.3 THE SVP 
RETURNS 
THE IGC 
INFORMATION. 



640 ~ 



6.4 THE MERCHANT 
SERVLET DISPLAYS 
IGC INFORMATION. 
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PURCHASER 




STORED VALUE 
PROCESSOR 



6.5.1 PURCHASER 
CLICKS ON 
NOTIFICATION 
STATUS 



6.5.4 PURCHASER 
ENTERS ORDER 
NUMBER. 



654 



682 



653- 



6.5.3 A SCREEN 
REQUESTING THE 
ORDER NUMBER IS 
DiSPUYED. 



660 - 



6.6 THE MERCHANT 
SERVLET CALLS 
GET ORDER. 



670 



6.7 THE SVP 
RETURNS 
THE ORDER 
INFORMATION. 



6.8 PURCHASER 
UPDATES RECIPIENT 
INFORMATION 



6.8 THE MERCHANT 
SERVLET DISPLAYS IGC 
INFORMATION. 



^680 



691 



6.9,1 PURCHASER 
CLICKS ON SUBMIT. 



692 



6.9.2 THE MERCHANT 

SERVLET CALLS 
UPDATE RECIPIENT 



6.13 IF THE 
PURCHASER 
REPLIES TO THE 
NOTIFICATION 
FAILED MESSAGE 
IT WILL CONTAIN 
THE MERCHANTS 
CUSTOMER SERVICE 

EMAIL BOX. 


613 



6,12 THE MERCHANT 
SERVLET DISPLAYS 
THE UPDATED 
INFORMATION 
AND A MERCHANT 
HOTLINK. 



612 



610 



6.10, 6.11 THE SVP 

updates the 
recipient and sets 
the notification 
sent field to "sent" 
and resends 
notification 
message if 
neccessary.it 
returns an 
acknowledgement. 
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MERCHANT 



701 



MERCHANT 
ADMINISTRATION 
APPLICATION 



7.1.1 MERCHANT CLICKS 

ON MERCHANT 
ADMINISTRATION ICON. 




7.1.2 WEB SERVER 
RETURNS PAGE THAT 
REQUESTS USERNAME 

AND PASSWORD... 


S 



STORED 
VALUE 
PROCESSOR 



-712 



720 



730 



7.1.3 MERCHANT ENTERS 

USERNAME AND 
PASSWORD. OK BUTTON 
IS PRESSED. 




7.2 WEB 
SERVER CALLS 
GET MERCHANT 
ID. 




— ^ 
7.3 SVP LOOKS UP THE 
MERCHANT RECORD 
AND VALIDATES THE 
PASSWORD. IT RETURNS 
THE MERCHANT ID. 






\ 





7.4.1 
DID THE 
MERCHANT ENTER THE 
-CORRECT PASSWORD ^ 
? 



NO 



742 

^ 



7.4.2 WEB SERVER 
RETURNS AN ERROR 
MESSAGE. 



TO STEP 
711-1 





743 

y 


YES 


7.4.3 WEB SERVER RETURNS A 
WELCOME PAGE WITH OPTIONS 
FOR MERCHANT SETUP, 
MERCHANT REPORTS, EMAIL 
CUSTOMER SERVICE OR EXIT. 






1 
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751 

d. . 

7.5.1 MERCHANT 
PRESSES MERCHANT 
SETUP. 



761 

d 

7.6.1 WEB SERVER 

CALLS GET 
MERCHANT INFO 



762 

d 

7.6.2 THE SVP 
RETURNS THE 
DATA. 



772 



7.7.2 MERCHANT VIEWS 
AND/OR EDITS THE 
INFORMATION. THEN 
PRESSES THE OK 
BUTTON. 



771 



7.7.1 WEB 
SERVER DISPLAYS 
THE INFORMATION 
ACCORDING TO READ 
AND WRITE PROPERTIES. 



780 



7.8 WEB SERVER 
CALLS UPDATE 
MERCHANT INFO 



710- 



7.10 WEB SERVER 
RETURNS DATA 
SUCCESSFULLY 
UPDATED. 



7.11.1 MERCHANT 
PRESSES MERCHANT 
REPORTS. MERCHANT 
SELECTS WHICH 
REPORT AND 
PRESSES OK. 



711-1 



7.11.1 WEB SERVER 
CALLS THE SPECIFIC 
REPORTS FROM SVP 



—^^^ 

711-4 



7.11.3 WEB SERVER 
DISPLAYS THE 
FORMATTED REPORT. 



711-3 



790 



7.9 THE SVP 
RETURNS 
WHETHER THE 
DATE WAS 
UPDATED. 



711-2 



7.11.2 THE SVP 
RETURNS THE 
REPORT DATA. 
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DECLARATION AND POWER OF ATTORNEY 
As a below namal inventor, ! hereby declare that: 

My residence, post office and citizenship are as slated below next to my name, 

I believe I am the original, first and sole inventor (if only one name is iisted below) or an original, first and 
joint inventor (ifplura] names arc listed below) of the subject matter claimed and for which a patent is sought 
on the STORED VALUE ELECTRONIC CERTIFICATE PROCESSING, the specification of which 

^ is attached hereto. 

H] was filed on as Application Serial >Jo. and was amended on (if 

i applicable). 

^\ hereby state that I have reviewed and understand tlie contents of the above identified specification, including 
*lhc claims, as amended by any amendment refen-ed to above. 



h acknowledge (he duty to disclose infomiation which is known lo me to be materia! to patciitabihly in 
faccordance witli Title 37, Code of Federal Regulations, Section L56. 

hereby claim foreigii priority benefits under Title 35, United States Code, Section 119 of any foreign 
f application(s) for patent or inventor's certificate listed below and have also identified below any foreign 
}f application for patent or inventor's certificate having a filing date before that of the application on which 
priority is claimed; 

^ Prior Foreign Applications(s): 

' Number Country Day/Month/Ycax filed Priority Claimed 

PCT/USOO/05039 PCT 25 Febmary 2000 

□ 

Thereby claim the benefit under 35 USC §1 19(e) of any United States provisional appHcation(s) listed below. 
Prior Provisional AppIicationCs); 

Application No. Filing Date; 

60/121,956 Fcbniaiy25, 1999 

i hereby claim the benefit under Title 35, United Stales Code, Section 120 of any United States applicatjon(s) 
listed below and, insofar as the subject matter of each of the claims of this application is not disclosed in tlie 
prior United Slates application in the manner provided by the firsl paragraph of Title 35, United States Code, 
Section 112, I acknowledge the duty to disclose material infomiation as defined in Title 37, Code of Federal 
Regulations, Section 1 .56 which occurred between the filing date of the prior application and the national or 
PCT international Cling date of this application: 



Prior U.S. Appiication(s): 

Serial No. 



Fi iing Date 



Status: Patented, Pending, Abandoned 



AUG-23-2001 THU 08:20 i 



1 ^! 



Sun En( 



FAX NO, 6056Hb7250 



^2 



Attomey Docket No, 53588-0510 



I hereby declare that all statements made herdn of my Own knowledge are true and Uiat all statements made on 
infonnation and belief are believed to be true; and further that these statements were made with the knowledge 
lhat willfiU false statements and the like so made arc punishable by fine or imprisonment, or both, under 
Section 1001 of Title 18 of the United States Code and that such willful false statements may jeopardize the 
validity of the application or any patent issued thereon. 

I hereby appoint the following attomey(s) and/'or agent(s): Edwai-d A. Becker, Reg. No^^^JU??; Marcel K, 
Bingham, Reg. No.^42j327; Carl L. Brandt, Reg. No. 44,555; Brian D. Hickman, Reg. No. 35J94; Christopher 
J. Palermo, Reg. No. 42.056 : Carina M. Tan, Reg. No. 45.76D: Bobby K. Tmong, Reg. No.,.12^9; Craig G. 
Holmes, Reg. No. 44.770: Van Mahamedi, Reg. No. 42,8.28 and John D. Henkhaus, Reg. No, 42j656j_all of 

HICKMAN PALERMO T RUQ NG & BECKER LLP 
1600 Willow Street 
San_Josc,CA 95125-5106 

with full power of substitution and revocation, to prosecute this application and to transact all business in the 
Patent and Trademark Office connected therewith, and all future coirespondence should be addressed to them. 



Full name of sole or first inventor: William L. HONNEF 




Inventor's signature: f Y^\^S=L^ St 
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- Residence: 1595 Calle Aurora, Camarillo, California 93010 


i: Citizenship: USA 
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